1. Field of the Invention
The present invention is related to the field of data transmission over networks, and more specifically to devices and methods for minimizing the startup delay of streaming media.
2. Description of the Related Art
Networks are increasingly used to transmit data. The data can be for various media, such as audio or video, and is usually organized in groups that are called frames. When such data is transmitted continuously, it is also called streaming media. The transmission can either be for live, or for canned media. Either way, the transmission has to be in real-time, or in delayed real-time.
A fundamental requirement for streaming media is that it has to be played at a constant rate. Packet networks, however, may transmit data asynchronously. Therefore, for streaming media to be transmitted over packet networks, strict timing requirements have to be met in order to achieve high-quality media play out. Furthermore, where there are two related but separate streams of media (such as audio and video), they have to be time-synchronized.
The bandwidth of the channel is intended to be wider than what is required by the streaming media. The channel bandwidth, however, is occasionally subject to congestion. This causes play out of streaming media to exhibit the problem of network jitter, if played out in real-time. This means that what is played out might be momentarily discontinued, if the bandwidth of the network is momentarily constricted to less than the required bandwidth of the streaming media.
Referring to FIG. 1, the problem of network jitter has been solved in the art by introducing a de-jitter buffer at the receiving end. A server or proxy 110 transmits data to a client or receiver 160 through a network 150. The server 110 includes a path 112 for data received from a source, and transmitted to the network 150. Typically, the server 110 includes a buffer in the path 112, such as a transmit buffer 114.
Importantly, the client 160 includes a fixed size de-jitter receive buffer 162. The buffer 162 first fills up to its size, and then starts playing out. While playing out, the buffer 162 is emptied at the same rate as it is filled. Constrictions in bandwidth affect only the fullness of the buffer, not the play out, therefore preventing network jitter. The larger the size of the buffer, the more the network jitter phenomenon is abated.
A problem generated by the de-jitter receive buffer 162 is a phenomenon called startup delay. The phenomenon is now described in more detail below.
Referring to FIG. 2, the fullness of the buffer 162 is plotted against a time axis as a line 210. Initially the buffer 162 fills up to its size fy, which it reaches at time point 212. For illustration purposes, the line 210 is shown in an approximate manner as a ramp. However, the line is actually piecewise linear, shaped more like a stair.
After reaching its full size fy, playout begins. Then the buffer 162 ideally remains at the same fullness level. Again, that is shown as a straight line only for illustration purposes. The fullness level buffer 162 may temporarily go lower than the ideal.
It will be appreciated that the larger the size fy is, the longer time it takes to reach that level. The time between zero and time point 212 is called the startup delay. The startup delay causes the play out to be in delayed real-time, compared to when the data is received.
The startup delay can be as long as one second or more, which is a problem. It is even more of a problem when the user is channel surfing, i.e. switching quickly from one channel to another. With every new channel switch, there is another startup delay.